Security-JAWS 第10回レポート #secjaws #secjaws10

こんにちは、臼田です。

Security JAWS 第10回が開催されましたのでレポート致します。

Security JAWS 【第10回】 勉強会 2018年8月3日(金) - Security-JAWS | Doorkeeper

レポート

Session1:T3Realize 合同会社 横堀 達也さん「すぐ出来る！デスクトップSSOはサーバレスで」

• SSOって言われるとどんなことを思うか？
  • できれば使いたいよね
  • でも導入できていないよね
• すぐにSSOできる方法があります！
• SSOとは
  • 利用者としては一回ログインすればいろんなシステムにアクセスできる
  • システム的には識別、認証、認可をうまいことやることが求められる
  • 全システムの仕様なんて知らなくて調整が難しいことが多い
• 識別とは
  • ログインする各システムでIDが必要
  • システムによってはIDが自動で作られる場合もある
• 認証とは
  • SSOって言われるとここだと言われることが多い
  • SSOの仕組みとしてID/PASS代理入力やSAML等がある
• 認可
  • ユーザに権限を割り振る
  • SSOで権限を指定しない場合と、指定する時がある
• SSOの仕組みについて
  • たくさんある
    • 代行入力
    • リバプロ
    • Agent
    • 統合Windows認証
    • SAML
    • OpenID Connect
  • SAMLは結構いろんなシステムに対応している、現役
  • 最近はOpenID Connectも多い
  • どのやり方がいいのか
    • 代行入力とSAML押し(個人的な見解)
    • 代行入力は原始的だがすべてのシステムに対応できる
    • SAMLは各種SaaSのデファクト、応用の幅が広い
• 何を使えばすぐにできるの？
  • AzureADです！
    • サーバレスSSO基盤
    • SAML、代行入力、OpenID Connectにも最近対応
    • Offic365についてくる
    • 圧倒的に使える
    • 大規模だとAzureAD P1が必要なので注意
• すぐできるSSO
  • AWSマネジメントコンソールにSSOする環境を作る
  • 詳細手順はスライド参照
  • AzureADの設定
    • AzureADにユーザを作る
    • アプリケーションを作る
      • AWSを選べばすぐにできる
    • xmlファイルをダウンロード
  • AWS側
    • IAMのIDプロバイダーからプロバイダの作成
    • SAMLプロバイダーでxmlをインポート
    • SSOユーザに割り当てるRoleを作る
    • 連携するためのIAMポリシーとユーザを作る
  • AzureAD側
    • 紐づけ作業
    • IAMユーザの情報を設定
    • SSOできるユーザを設定する
    • AWSのRoleが確認できる
  • パソコン側
    • Windows10なら設定のアカウント設定からUserの設定
    • SSO用URLを開くとSSOでログインできる！
• サーバレスを活用すればデスクトップSSOもシンプルにできる
• SAMLなら色んな情報を入れられるので応用範囲が広い

感想

簡単にSSOを実現するための選択しとしてAzureADは優秀ですね。

AWSは他にもいろんなユーザデータベースと連携できますので、マネジメントコンソールをSSOで入れるようにして楽してみましょう！

Session2:トレンドマイクロ株式会社 南原 正樹さん「Trend Micro Security Smart Check でSecure CI/CD Pipelineを」

• DevOpsとは
  • 開発と運用がうまくやる
  • うまくやるためにCI/CDとかを実現したい
• CI/CDとは
  • あとでググってください
• DevOps × Security = DevSecOps
  • 従来のように運用段階に移ってからセキュリティを実装するとDevOpsに合わない
  • DevOpsの素早い開発を邪魔せずに各所でセキュリティを組み込む
• Pipelineにおけるセキュリティ
  • Code/Buildは静的なセキュリティ
  • 実行環境の保護は動的セキュリティ
• Developのフェースに存在するリスク
  • Docker Hub等の古いライブラリをそのまま使う
  • 脆弱性を持ったままになる
• Managed Service やEKSなどにどうやって適用していくか
• Deep Security Smart Checkを提供予定！
  • 機能
    • コンテナイメージ内の不正プログラム検索
    • コンテナイメージ内に存在する脆弱性の検出
    • 継続的な脆弱性・ウイルスの監視とアラート
    • スキャン履歴の確認
  • セキュリティをシフトレフとする！
  • 運用イメージ
    • Pushされたらスキャンして問題があったらSlackなどに通知
    • 問題なければコンテナをデプロイする
  • アーキテクチャ
    • Invokeされたら複数のコンテナを起動して各種スキャンを行う
• UIデモ
  • ダッシュボードでマルウェアや脆弱性の情報のサマリ表示
  • スキャン結果では脅威レベルと見つかった数、脆弱性の内容など表示
• これまでDeep SecurityはEC2寄りだったが、ECSやEKS等のマネージドサービスにはSmart Checkで対応していく
• トライアルしてみたい方はトレンドマイクロさんにお声掛けください！
• https://www.trendmicro.com/en_us/business/products/hybrid-cloud/smart-check-image-scanning.html

感想

コンテナのセキュリティは運用でカバーしようとすると大変なので、うまくDevOpsのサイクルに盛り込んでいきたいですね。

リリースが楽しみです！

Session3:クラスメソッド株式会社 AWS事業本部 プロダクトグループ 田子昌行さん「小さな発見を大きな安心に 〜insightwatchのご紹介〜」

• AWSを使っていると困ること
  • 構築時のセキュリティが不安
  • ビジネスに注力したくてあまりセキュリティに費用をかけれない
  • AWS環境が複数あって、アカウントごと確認することが大変
• クラスメソッドの取り組み
  • AWSはたくさんのアップデートがある
  • 反面、知らずに間違った使い方をする可能性がある
    • 例えばS3の情報を誤って公開する、使っていないIAMユーザを放置する、など
  • これまでクラスメソッドが培ってきたノウハウでなにかできないかと思ってinsightwatchを開発
• insightwatchとは
  • 誰でも簡単にご利用のAWS環境がセキュリティのベストプラクティスに則っているか確認
• 特徴
  • CISベンチマークに基づくセキュリティチェック
    • 米国CISの認定プロダクト
  • チェック結果レポートと設定のガイドを提供
    • 弊社ブログやAWS公式ドキュメントを表示
    • レポートが出せるので監査にも対応できる
  • 複数AWSアカウントを統合して管理
    • 組織とプロジェクトという枠でAWSアカウントを整理できる
    • プロジェクトに複数のAWSアカウントを登録できる
    • プロジェクトでまとめてチェックを行うことができる
  • 使い方は簡単
    • メールアドレスを登録してサインアップ
    • IAM Roleが必要だけど、CloudFormationのテンプレートがある
    • Roleを作成したら、すぐにスキャン！
  • どなたでも、無料でお使いいただけます
• insightwatchが提供するメリット
  • ベストプラクティスに従った適切なセキュリティ設定になっているか確認できる
  • 標準化されたシステム設定によりコストを掛けずにリスクを低減し、システム監査に役立てる
• 中身の話
  • システム構成
    • SPA
    • REST API
    • 認証はCognito User Pools
    • チェックはAWS Batch
• まとめ
  • セキュリティは定期的なチェックが必要
  • 簡単にできるのでぜひ定期的にやってください
  • 小さな発見と対策が大きな安心につながります
  • insightwatchは誰でも安心してAWSを利用できるようにしたい
  • 今後はAWSのSecurityCheckListやIAMベストプラクティスに対応していきたい

感想

手前味噌ですが、簡単につかえるのでぜひご利用してください！やってみたブログはこちら

[AWS]insightwatchを新規登録して使ってみた #AWSSummit

Session4:Netskope Japan株式会社 橋本一文さん「設定の誤りや外部脅威を防御するNetskopeのAWSセキュリティ自動化」

• Netskopeってどんな製品？
  • CASB
  • クラウドWebプロキシのような製品
  • SaaSとのAPI接続も可能
• Netskope製品の基本的な考え方
  • どのSaaS,IaaS,Webに接続してもNetskopeを経由してポリシーを適用
• NetskopeはSaaSとは異なる視点でIaaSのセキュリティを考えている
• CISOが考える機密データ漏洩や脅威につながる課題
  • 誤設定、誤った構成による脆弱性
• 過去に起こったIaaSの情報漏えいは単純な設定ミスが多い
• 何ができるのか
  • 行動の可視化と制御
    • SaaSでも基本
    • いつ誰がどのサービスをどこで操作したか記録
  • 高度な脅威防御
    • 特にアノマリ検知が優れている
    • BoxからダウンロードしたファイルをそのままGoogle Driveにアップロードした
      • 退職する人が退職時にやりがち
  • CISベンチマークに基づく継続的なセキュリティ評価
• demo
  • ユースケース1
    • 特定ユーザのEC2起動を禁止
    • ブロックしたらAlertが上がってくる
    • すごく早い
  • ユースケース2
    • S3バケットに出入りする機密データをリアルタイムに保護する
    • マイナンバーを含むデータのアップロードをブロック
    • ブロックしたら、操作したユーザに操作した理由を入力するように求めることも可能
  • ユースケース3
    • APIにてS3バケット内のコンテンツをDLPスキャンする
    • リアルタイムでもAPIベースでも同じポリシーで検知できるのはメリット
    • ウイルス検知も可能
  • ユースケース4
    • クラウド環境をCISベンチマークにそってチェック
    • サービス毎にチェックする
  • ユースケース5
    • CloudTrailとの統合
    • 1つの画面で見れる
• まとめ
  • IaaSセキュリティはSaaSとは違う見方が必要
  • リアルタイムと非リアルタイムで制御/検知が可能
  • IaaS,SaaS,Webを同時に管理したいならNetskope！

感想

プロキシとして機能するので許可していないものを止められるのは非常に強力でいい機能ですね。

AWSに限らずいろいろなIaaS、SaaSを利用している環境では特に行きそうなので、ぜひ使ってみたいですね。

Session5:株式会社リクルートテクノロジーズ 徳田 聡介さん・安東 美穂さん「ほんとうに大事なサービスを守れるのか！？実運用に向けてAWS WAFを検討してみた」

• Recruit-CSIRT
  • SOCの他にRed Teamやインシデントレスポンスもやっている
• なぜAWS WAFを検証するのか
  • これまでのセキュリティ対応はオンプレミスでやっていた
  • 最近はクラウド環境でのアプリ開発が多かった
  • 社内の主流はAWSだった
  • コストや柔軟性からAWS WAFを検討したが治験も少なかった
  • 検証するしか無いよねってなった
• 検証してみた
  • ゴール
    • どれくらい検知するか
    • どれくらい過検知するか
  • 構成
    • CloudFront - ELB - EC2
    • CloudFrontにWAF適用
    • レスポンスコードで動作を確認
    • 検証データを作るスクリプト
    • 検証用データ種類
      • 攻撃系
        • Sqlmapのログをとって攻撃リクエストにした
        • Burp Suite Proのログから攻撃リクエストにした
        • CSIC2010
      • 正常系データ
        • CSIC2010
        • 実アプリ
  • そもそもAWS WAFとは
    • CloudFrontやALBに組み込んで利用できるWAF
  • マネージドルール
    • マーケットプレイスから利用できるセキュリティベンダーのルール
    • 自動で更新されるため運用負荷は小さい
    • 検証に使ったマネージドルールは主にF5とFortinet
  • カスタムルール
    • 今回はXSSとSQLiのみ
    • 複数の条件を入れるとANDになるので注意
      • 今回はone rule one condition
    • RuleはOR条件
    • マネージドルールはWebACLあたり1つだけ利用可能
  • WAF設定
  • Conditionの落とし穴
    • デコード方法を適切に設定しないといけない
  • 検証結果
    • 攻撃はそれなりにブロック
    • 誤検知も少ない
  • 所感
    • 一部ベンダーのマネージドルールが比較的いい
    • カスタムルールは堅い守り
    • 実運用にはいくつか課題がありそう
• セキュリティ運用を考えてみた
  • 課題になりそうなこと
    • 誤遮断
    • チューニング
    • ログ
  • 遮断された正常系リクエスト
    • Substr()がだめだった
    • 特定のSQL関数を遮断する可能性あり
    • SQL構文を遮断する可能性あり
    • 事前に正常系の通信で要検証
    • Select Shopなどの正常な文言も引っかかる可能性あり
  • Condition設定はとてもシンプル
    • 中身はよくわからない
    • 誤検知が判明しても除外がやりづらい
  • チューニングが難しい
    • ポリシーの中身がブラックボックス
  • ログ
    • Sampleログがみれるくらい
    • APIのGetSampledRequestsは使える
    • すべてが出ない
    • 検知箇所、リクエストbody、レスポンスは含まれない
    • CloudWatchでイベント検知してLambdaでとったり
    • Lambda@Edgeでとったりして工夫する
  • セキュリティ運用などうなる？
    • 導入時はAWS WAFならコンソールでポチポチで早い
    • 運用開始してからもカスタムルール追加していくくらい
    • アラート対応は基本は遮断するので細かく見ないでチューニングする程度、細かくはできない
  • AWS WAF向きなユースケース
    • PCI対応
      • AWS WAFはPCIDSS 3.2に準拠
    • 特定のリクエストの遮断
      • 判明している脆弱性の攻撃を防ぎたい
      • 特定のUser-Agentでくるbotを遮断したい
    • 動的なFWとして活用
      • ブラックリストIP/ホワイトリストIP
      • マーケットプレイスの製品との組み合わせ
      • SIEM連携
  • AWS WAFセキュリティオートメーションのような使い方

感想

ガッツリ検証していて非常に興味深い内容でした！

AWS WAFも含め、それぞれのWAFは特徴があるのでうまく使い分けて利用したいですね。

マネージドルールはネ申！

Session6:アマゾン ウェブ サービス ジャパン株式会社 松本 照吾さん「AWS Public Sector Summit Re:cap（セキュリティ観点から）」

[slideshare id=108707717&doc=sjawspubsecsummitrecap-180805231607]

• ホワイトハウスもAWSのお客様！
• AWS ConfigのRDK(Rule Developer kit)を使っている方がいたらGithub等にFeedbackしてください！
• Public Sector Summitとは
  • 参加者14000名以上
  • セッション100以上
  • 政府機関、自治体以外に医療などもある
  • Aamazonやクラウド文化、組織改革の話もある
  • 12-factorや2ピッツァも政府機関で採用されているらしい
• どんな話があったか
  • 世界初のクラウド学位
  • 米国陸軍のサイバーセキュリティ共通プラットフォーム
  • 米国証券取引委員会の取引データ監視
  • City on a Cloud Award
    • Alexaを使った状況通知
• GovCloudの存在
  • 2011年に西海岸にOpen
  • アメリカの規制に対応するためのもの
  • 米国市民のみの論理/物理アクセス
  • 「利用前にパスポートもしくはグリーンカードを見せてください」
  • サービスは同じ
  • 東海岸にGovCloudがOpenした
• 特別なリージョンでないと政府機関では使えないか
  • No!!!
  • 米国においても多くの政府機関が通常リージョンを使用
  • シンガポール、オーストラリア、イギリス等でも政府機関が通常リージョンを使用
• キーノートの内容
  • たとえ最弱な日でもクラウドはよりセキュアだ
    • オンプレと比較して、どんなときでもセキュア
  • 政府機関がクラウドを利用しているのはセキュアだから
  • サービスをどんどん作り変えていったり、大量のデータの分析を行う必要があるのでレガシーなやり方では間に合わない
• セッション
  • 退役軍人省のDevSecOpsの話
    • https://aws.amazon.com/jp/blogs/publicsector/in-honor-of-our-veterans/
    • MicroServiceは自然な移行
    • 1日6回の継続的なデプロイを行っている
    • DevOpsのスピード感に間に合わない既存環境
    • セキュリティも間に合わない
    • 単なるツールのSecure CI/CDがDevSecOpsではない
    • いろんなツールを利用している
    • MeltdownやSpectrumも大丈夫だった
    • レガシーシステムでは互換性の問題があったので数年かけて移行
    • セキュリティ部門とコミュニケーションが必要
      • あいまいな定義を具体的に落とす
    • 空軍でもDevSecOps
  • 移民局によるDevSecOps
    • DevSecOpsはツールの話になりがちだが、このセッションは対話の話
• まずはこれを実践していこう
  • 自分たちのライフサイクルを理解して開発部門とセキュリティ部門でなるべく多く話し合う
  • 管理作を集める
  • 人手に寄るアクションの文書化
  • 人によるアクセスの排除
  • デプロイワークロードのゴール設定
• 資料はすべて視聴、閲覧できます
• まとめ
  • DevSecOpsは人生には早すぎる？
    • そんなことないがツールだけじゃなくて組織や文化が大事
• AWS Innovate Japan 2018もあります！

感想

米国では進んでいるPublic Sectorの事例が出てきているのにびっくりしました！

日本でも「クラウド・バイ・デフォルト原則」というのが出ているので

日本の政府や自治体でもDevSecOps進んでほしいですね(白目

さいごに

今回もそれぞれ濃い話が聞けました！

CASBはAWS以外の利用でもガバナンスを効かせられるので活用していきいたですね。

DevSecOpsは本当に進んでほしいですね。